Protocols that use either or both public-key cryptographic techniques and symmetric-key cryptographic techniques are often used to establish secure communications across an untrusted network or other communication link. Typically, public-key cryptography has better security properties but is more expensive computationally than symmetric-key cryptography. Thus, the two types of cryptography may be combined to use public-key techniques to negotiate a symmetric cipher between two entities. The symmetric-key cipher may then be used for bulk data transfer between the entities. Secure Socket Layer (SSL) and Transport Layer Security (TLS) are widely-used examples of secure communication protocols that have this form, as well as IPSec (Internet Protocol Security) when security associations are negotiated using RSA-based (Rivest, Shamir & Adleman) mechanisms for IKE (Internet (or IPsec) Key Exchange).
Secure communication protocols often add a computational cost to each secured connection. For server computers providing many simultaneous secure connections to client computers, the additional computational overhead imposed by secure communication protocols can be significant. To decrease the computational overhead of secure communication protocols for computers providing large numbers of secure connections, there are various devices that specialize in terminating secure connections.
These secure connection termination devices manage the cryptographic and other security related aspects of the connection, thereby relieving server systems providing services to client systems of the additional overhead imposed by the secure connection. One type of secure connection termination device is configured to accelerate network transactions, and hence is often termed a transaction accelerator.
A transaction accelerator such as that described in U.S. Pat. No. 7,120,666 (McCanne) can offer performance improvement for operations across a wide-area network (WAN), but only when the data being communicated is either intelligible (i.e., the transaction accelerator can interpret at least parts of the protocol) or repeating (i.e., identical data crosses the network in identical format). The use of secure communication protocols such as SSL and TLS thus typically frustrates transaction acceleration, because cryptography (by design) renders encrypted data unintelligible and non-repeating.
A method of securing end-to-end communications between a client and a server in which cooperating transaction accelerators are employed is described in U.S. Patent Publication No. US2007/0038853 (application Ser. No. 11/489,414), and involves the use of separate split-terminated secure protocol sessions between a transaction accelerator and the client, and between another transaction accelerator and the server.
However, transaction accelerators generally are not equipped to participate in authentication schemes between a client and a server. Therefore, they cannot perform optimally in computing environments in which a client and a server perform mutual authentication, especially when the authentication is based on digital certificates.
For example, in a client-server application such as Lotus™ Notes by IBM™, a Lotus Notes client and a Lotus Domino server each possess one or more digital certificates issued by certificate authorities. When the client wishes to open a secure communication connection with the server, each sends the other a copy of a certificate issued by a certificate authority that the other trusts.
If the client and the server successfully verify the other's certificate, they then agree upon a session key (e.g., a symmetric encryption/decryption key) and subsequently use that key to secure their communications. Because the key is only shared among the entities that participated in the mutual authentication process, a traditional transaction accelerator or similar entity cannot participate in the resulting client-server communication connection and therefore cannot optimize client-server communications.
A traditional transaction accelerator may attempt to solve this problem by importing client certificates, which would allow it to proxy for those clients and receive session keys for communicating with a server. However, this is an impractical solution because there is likely a vast number of clients, and therefore a large number of certificates would have to be maintained on the transaction accelerator. In addition, because of the ever-changing nature of clients (e.g., new clients appearing for new employees, old clients disappearing as employees depart), such a pool of client certificates would need constant updating.